-
Notifications
You must be signed in to change notification settings - Fork 407
Add linear mode #6670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add linear mode #6670
Conversation
🎭 Playwright Test Results⏰ Completed at: 11/19/2025, 05:59:04 PM UTC 📈 Summary
📊 Test Reports by Browser
🎉 Click on the links above to view detailed test results for each browser configuration. |
🎨 Storybook Build Status✅ Build completed successfully! ⏰ Completed at: 11/19/2025, 05:49:31 PM UTC 🔗 Links🎉 Your Storybook is ready for review! |
Bundle Size ReportSummary
Category Glance Per-category breakdownApp Entry Points — 3.14 MB (baseline 3.14 MB) • 🔴 +581 BMain entry bundles and manifests
Status: 3 added / 3 removed Graph Workspace — 921 kB (baseline 913 kB) • 🔴 +8.56 kBGraph editor runtime, canvas, workflow orchestration
Status: 1 added / 1 removed Views & Navigation — 8.03 kB (baseline 8.03 kB) • ⚪ 0 BTop-level views, pages, and routed surfaces
Status: 1 added / 1 removed Panels & Settings — 307 kB (baseline 307 kB) • ⚪ 0 BConfiguration panels, inspectors, and settings screens
Status: 6 added / 6 removed UI Components — 143 kB (baseline 130 kB) • 🔴 +12.7 kBReusable component library chunks
Status: 6 added / 5 removed Data & Services — 12.6 kB (baseline 12.6 kB) • ⚪ 0 BStores, services, APIs, and repositories
Status: 3 added / 3 removed Utilities & Hooks — 2.94 kB (baseline 2.94 kB) • ⚪ 0 BHelpers, composables, and utility bundles
Status: 1 added / 1 removed Vendor & Third-Party — 5.32 MB (baseline 5.32 MB) • ⚪ 0 BExternal libraries and shared vendor chunks
Status: 3 added / 3 removed Other — 3.88 MB (baseline 3.9 MB) • 🟢 -12.2 kBBundles that do not match a named category
Status: 19 added / 19 removed |
Since linearview is no longer built on top of the canvassplitteroverlay, attempted changes to allow for an off-side-panel are no longer required
Justice for ducks
reka-ui was less kind with initial styling. Both require initial size in percent. This makes it impossible to properly specify that the initial size should be the minimum content size. My workaround is to set the initial size to 1%. This causes visually correct appearance, but in reka-ui, the gutter handle would need to be dragged the length of the minimum content before seeing actual visual change in sizing. This felt super awful.
Run button is always on screen, text boxes scale up to a reasonable max
christian-byrne
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| tabActivationHistory.value.shift() | ||
| } | ||
|
|
||
| useCanvasStore().linearMode = !!loadedWorkflow.activeState.extra?.linearMode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
big nit: Generally I think of the dependency layers as going from:
- libraries
- base
- platform
- workbench
- renderer
If we think of the workflow management happening at platform layer, we would generally not want it to import and use the canvas store, which operates more at the renderer layer. Instead, there could be hooks, events, or signals used to allow lower levels to react to a workflow changing. Then, the linear mode logic could be confined to its layer. A good rule of thumb is that you should be able to remove something in the lower level and not break something above.
However, this standard/architecture is not really enforced effectively at all and definitely shouldn't block a PR at this stage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was getting a similar smell. I'll make a note to follow up in a future PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: This sort of highlights a problem we have where all the app state is bootstrapped in (and tied to the lifecycle of) the GraphView. Because in a perfect world, the LinearView and GraphView would be side-by-side (rather than parent-child) and the router could be used to switch between them. But I am guessing that was not really possible to do easily in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. Having a router based implementation would be preferred, but we'd need quite a bit of refactoring to get there. GraphCanvas also owns a lot of state and I'm not terribly happy about needing to put a v-show on it instead of a v-if/v-else
| } | ||
| }) | ||
| } | ||
| function openFeedback() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We should make a command in command store for this since it's used in multiple places now.
See also: #6642
┆Issue is synchronized with this Notion page by Unito